(?) 



(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(11) EP 1 032 179 A1 

EUROPEAN PATENT APPLICATION 



(43) 


Date of publication: 


(51) lntCl7: H04L 29/06, H04L 12/56 




30.08.2000 Bulletin 2000/35 


(21) 


Application number: 99301481.0 




(22) 


Date of filing: 26.02.1999 




(84) 


Designated Contracting States: 


• Kriaras, loannis 




AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


Chippenham, Wiltshire SN15 4JZ (GB) 




MC NL PT SE 


• Paparella, Andrea 




Designated Extension States: 


Swindon, Wiltshire SN5 9RF (GB) 




AL LT LV MK RO SI 








(74) Representative: Williams, David John et al 


(71) 


Applicant: LUCENT TECHNOLOGIES INC. 


Lucent Technologies UK Limited, 




Murray Hill, New Jersey 07974-0636 (US) 


5 Mornington Road 






Woodford Green, Essex IG8 0TU (GB) 


(72) 


Inventors: 




* 


Chen, Xiaobao 






Swindon, Wiltshire SN5 7EP (GB) 





Q. 

Q 

gr 

CD 

O 
o 



(54) Mobile IP supporting quality of service 

(57) There is disclosed a method of establishing a 
quality of service session between a correspondent 
node and a mobile node. The mobile node has a home 
address in a home network is temporarily connected at 
a care-of address in a foreign network. The method in- 
cludes the steps of generating, in the foreign network, 



a modified reply message having a source address of 
the mobile node's care-of address and a destination ad- 
dress of the correspondent node, and transmitting the 
modified reply message. A mobile IP environment ca- 
pable of supporting such a quality of service session is 
also disclosed. 
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Description 

Field of the Invention 

[0001] The present invention relates to messages 
conforming to the mobile Internet protocol (mobile IP) 
and sent from a host node in a network to a mobile node, 
and particularly to maintain a desired quality of service 
when any mobile host node changes its point of network 
attachment. 

Background to the Invention 

[0002] Current internet protocol (IP) technology and 
mobile IP technology enables a host terminal or host 
node which is normally connected in a particular net- 
work (the nodes 'home' network) to temporarily connect 
into a different network (a 'foreign' network) and still re- 
ceive IP packets or messages sent to the host terminal 
at its address in the home network. Such a host terminal, 
which changes its point of network attachment, is known 
as a mobile node. 

[0003] To still receive IP packets in the foreign net- 
work the mobile node must register with a so-called 
'home agent' in its home network. In registering with its 
home agent, the mobile node provides the home agent 
with a 'care-of address where it can be addressed in the 
foreign network. The home agent then monitors traffic 
in the home network, and if the home agent identifies 
an I P packet which is carrying a destination address cor- 
responding to the mobile node's home address in the 
home network, it intercepts the IP packet. The home 
agent then 're-packages' the IP packet and sends it to 
the node at the 'care-of address in the foreign network. 
[0004] The 'care-of address may be a co-located 
care-of address or a foreign agent care-of address. 
[0005] The technique of directing an IP packet, des- 
tined for an address in the home network, to a 'care-of 
address in the foreign network is known, in mobile IP, 
as 'tunneling'. It is important in tunneling the IP packet 
to the 'care-of address that certain information concern- 
ing the original IP packet is retained in the re-packaged 
IP packet. For example, as well as maintaining the orig- 
inal payload (or information portion) of the I P packet, the 
mobile node at the 'care-of address must still be able to 
identify in the 're-packaged' IP packet the source ad- 
dress from which the IP packet was originally sent and 
the home address of the mobile node in the home net- 
work. 

[0006] One technique known in mobile IP for 'tun- 
neling' an IP packet to a mobile node 'care-of address 
encapsulates the original IP packet into a new IP packet 
as the IP packet payload. That is the original IP packet 
is incorporated as the payload (or information portion) 
of the new IP packet without any change to its content. 
The 'care-of address is added to the new IP packet as 
the new destination address and the source address of 
the new IP packet is identified as the home agent. On 



receipt the mobile node at the 'care-of address removes 
the 'wrapping' on the new IP packet to recover the orig- 
inal IP packet. 

[0007] One disadvantage with this technique is that 
5 the repackaged IP packet does not facilitate the support 
of quality of service provisions in conformance with ex- 
isting IP quality of service standards. 
[0008] Each IP packet has associated therewith, and 
included in the IP packet, flow identification information 
io which identifies the quality of service associated with the 
IP packet transmission. This flow identification informa- 
tion is present in fixed locations of the IP packet, where 
quality of service (QoS) capable routing/switching ele- 
ments can locate it and operate in dependence on it. 
is However, with the encapsulation tunneling technique 
the flow identification information included in the IP 
packet by the source originating the IP packet is not 
available between the home agent and the 'care-of ad- 
dress. 

20 [0009] Thus the encapsulation technique in conven- 
tional mobile IP (one of which is known as IP-in-IP en- 
capsulation) shields the real source address (i.e. the ad- 
dress of the correspondent node) and real destination 
address (i.e. the mobile node's home address), as well 

25 as the protocol ID in the IP packets, from the home agent 
to the mobile node. In addition, encapsulation mobile IP 
also changes the payload infrastructure (the original IP 
header becomes part of the payload) and fails flow dif- 
ferentiation if routers are not changed accordingly so as 

30 to be able to detect the modifications or changes. 
Changes or even slight modifications of routers often re- 
quires a large amount of redesign and re-placement of 
all existing routers. This far more complicates the control 
and management of the networks. It may also cause 

35 problems in terms of security control and interoperabil- 
ity 

[0010] The quality of service (QoS) provisions pro- 
posed to be used in the Internet are defined by stand- 
ards, and in IP one known standard for quality of service 

40 signaling is called RSVP RSVP (Resource Reservation 
Protocol) is used in the Integrated Services Model 
(IntServe) quality of service framework defined by IETF. 
The Integrated Services Model was designed to provide 
special handling for certain types of traffic, provide 

45 mechanisms for applications to choose between multi- 
ple levels of delivery services for its traffic, and to pro- 
vide signaling for quality of service parameters at Layer 
3 in the OSI RM (signaling at layer 2 in ATM). 
[0011] IntServ defines two classes of services. The 

50 Controlled Load Class provides traffic delivery in the 
same way as when the network is unloaded ("better than 
best delivery"). The Guaranteed QoS Service Class de- 
livers traffic for applications with a bandwidth guarantee 
and delay bound. 

55 [0012] IntServ requires QoS capable nodes and a sig- 
naling protocol to communicate QoS requirements be- 
tween applications and nodes and between nodes. 
[0013] RSVP is the QoS signaling protocol used by 
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IntServ. RSVP provides receiver QoS requests to all 
router nodes along the transit Path of the traffic, main- 
tains the soft-state (Path/Reservation states), and re- 
sults in resources being reserved in each router. 
[001 4] For RSVP/lntServ quality of service to operate, 
the flow identification information must be in a fixed lo- 
cation in the IP packets. An RSVP session is configured 
by the host terminals exchanging so-called Path and 
Reservation messages prior to data transmission. 
[0015] To enable the quality of service control across 
the transit path between peer host terminals, each host 
terminal must therefore have the functionality to config- 
ure the necessary messages and recognise quality of 
service requests corresponding to an RSVP session. 
[001 6] Existing RSVP does not specify how to specif- 
ically process Path and Reservation (Resv) messages 
in the scenario of mobility control based on mobile IP. 
Moreover, the 'tunneling' of standard mobile IP (e.g. IP- 
in-IP encapsulation) disables the correct flow identifica- 
tion and classes of service differentiation. 
[001 7] It is therefore an object of the present invention 
to provide a technique which enables the quality of serv- 
ice requirement determined by the source of the mes- 
sage to be supported throughout the routing of the mes- 
sage to a mobile node's 'care-of address. 

Summary of the Invention 

[001 8] According to the present invention there is dis- 
closed a method of establishing a quality of service ses- 
sion between a correspondent node and a mobile node, 
the mobile node having a home address in a home net- 
work and being temporarily connected at a care-of ad- 
dress in a foreign network, the method including the 
steps of: generating, in the foreign network, a modified 
reply message having a source address of the mobile 
node's care-ot address and a destination address of the 
correspondent node; and transmitting the modified reply 
message. 

[0019] The present invention is generally applicable 
to any quality of service session which utilises request 
and reply messages between two terminals for config- 
uring a quality of service session. 
[0020] The method may further comprise the steps of: 
receiving, in the home network, a request message hav- 
ing a source address of the correspondent node and a 
destination address of the mobile node's home address; 
creating a modified request message by replacing the 
destination address of the request message with the 
mobile node's care-of address; and transmitting the 
modified request message to the foreign network, 
whereby the reply message is generated responsive to 
the modified request message. 

[0021] The method may further comprise the steps of: 
receiving in the home network, the modified reply mes- 
sage; creating a further modified reply message by re- 
placing the source address with the mobile node's home 
address; and transmitting the further modified reply 



message. 

[0022] The step of generating the modified reply mes- 
sage may be carried out in the mobile node. The step 
of generating the modified reply message may com- 

5 prise: generating a reply message having a source ad- 
dress of the mobile node's home address and a desti- 
nation address of the correspondent node; and replac- 
ing the source address with the mobile node's care-of 
address, thereby generating the modified reply mes- 

io sage. 

[0023] The step of generating the modified reply mes- 
sage may be carried out by proxy means in the foreign 
network associated with the mobile node. 
[0024] The method may further comprise the steps of: 

is responsive to receipt of the modified request message 
at the proxy means, sending a quality of service indica- 
tion signal to the mobile node, whereby the modified re- 
ply message is generated responsive to receipt of a 
quality of service acknowledgement from the mobile 

20 node. 

[0025] The correspondent node may generate the re- 
quest message and receives the further modified reply 
message. 

[0026] The correspondent node may be associated 

25 with a correspondent proxy means, whereby the corre- 
spondent proxy means generates the request message 
responsive to a quality of service request from the cor- 
respondent node, and the correspondent proxy means 
generates a quality of service confirmation responsive 

30 to receipt of the further modified reply message. 

[0027] The invention also provides a mobile IP envi- 
ronment capable of supporting a quality of service ses- 
sion, including a correspondent node and a mobile 
node, the mobile node having a home address in a home 

35 network and being temporarily connected at a care-of 
address in a.foreign network, the foreign network having 
means associated with the mobile node for generating 
a modified reply message having a source address of 
the mobile node's care-of address and a destination ad- 

40 dress of the correspondent node. 

[0028] The means may be provided in the mobile 
node or separate to the mobile node. 

Brief Description of the Figures 

45 

[0029] 



Figure 1 illustrates a network set-up including a 
home network, a correspondent network, and a for- 
eign network; 

Figures 2(a) to 2(b) illustrate the standard format of 
an IP packet; 

Figure 3 illustrates schematically a memory of a 
home agent of the home network; 
Figure 4(a) illustrates an IP packet constructed by 
the correspondent network for transmission to a 
mobile node in the home network, and Figure 4(b) 
illustrates the modification of that IP packet to re- 
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direct it to the foreign network according to the prior 
art; 

Figure 5(a) illustrates an IP packet constructed by 
the correspondent network for transmission to a 
mobile node in the home network, and Figure 5(b) 
illustrates the modification of that IP packet to re- 
direct it to the foreign network according to an alter- 
native technique; 

Figure 6(a) illustrates the I P packets of a Path mes- 
sage of a first section of a quality of service session 
in standard mobile IP; 

Figure 6(b) illustrates the IP packets of a Path mes- 
sage of a second section of a quality of service ses- 
sion in standard mobile IP; 

Figure 6(c) illustrates the general end-to-end struc- 
ture of a Reservation message in general IP; 
Figure 6(d) illustrates the general end-to-end struc- 
ture of a Reservation message of a second section 
of a quality of service session in mobile IP support- 
ing RSVP; 

Figure 6(e) illustrates the general end-to-end struc- 
ture of a Reservation message of a first section of 
a quality of service session in mobile IP supporting 
RSVP; 

Figure 7 illustrates the network arrangement of Fig- 
ure 1 adapted to support RSVP in mobile IP; and 
Figure 8 illustrates the steps of performing a pre- 
ferred implementation of an RSVP operation in mo- 
bile IP. 

Description of Preferred Embodiment 

[0030] Referring to Figure 1 there is shown a typical 
network set-up. A mobile node MN 8 to which a mes- 
sage is to be sent is normally located in a home network 
2. The mobile node MN 8 normally resides in the home 
network 2 at a particular address. This address is not 
necessarily a static IP address: the mobile node may be 
located at any physical point in the network, but a par- 
ticular IP address is associated with the mobile node it- 
self (rather than the physical point of connection). The 
home network may physically span a small office envi- 
ronment, or may span a number of countries. 
[0031] The mobile node MN 8 may be connected to 
the home network 2 by a wireless LAN, infrared link, 
wireless telephone link or via a direct Ethernet or token 
ring network hook-up. The term 'mobile node' does not 
imply that the node is connected to the network via a 
wireless link: rather it implies that the mobile node may 
move outside the home network 2 into a foreign network 
such as the foreign network 6 of Figure 1 , as will be dis- 
cussed in further detail hereinafter. 
[0032] The arrangement of Figure 1 also shows a cor- 
respondent network 4 including a correspondent node 
CN 10. For the purposes of illustrating the present in- 
vention, it is assumed that the correspondent node CN 
10 of the correspondent network sends a message to 
the mobile node 8 of the home network 2. The corre- 



spondent node may also be in a foreign network, that is 
a network independent of and distinct from the home 
network 2. However, the term foreign network is re- 
served for use to refer to a network which hosts a mobile 

5 node which normally resides in a different network (its 
home network). For the purposes of this illustrative ex- 
ample, the mobile node 8 of the home network 2 has 
moved to the foreign network 6. Thus the mobile node 
MN 8 is shown in the home network 2 in dashed lines 

io to indicate that it is normally present there, and is shown 
in the foreign network FN 6 in a solid line to indicate that 
it is temporarily present in the foreign network 6. 
[0033] The terms correspondent node and corre- 
spondent network are reserved for use to describe com- 

is munication peers of the mobile node 8. A correspondent 
node is a node (wh ich may be another mobile node) with 
which a mobile node is currently communicating: either 
receiving an IP packet or transmitting an IP packet. A 
correspondent network is used to refer to the network 

20 to which the correspondent node is connected. It should 
be appreciated that the mobile node may be communi- 
cating with a correspondent node in its own home net- 
work, and therefore the correspondent network may be 
the home network itself. 

2$ [0034] As can be seen from Figure 1, and as will be 
discussed further hereinafter, the home network 2 fur- 
ther includes a home agent 12. 

[0035] A brief example of the 'normal' communication 
between the correspondent node CN 10 and the mobile 
so node MN 8 will now be given. Referring to Figure 2(a), 
there is shown the general structure of an IP packet 1 4 
sent by the correspondent node CN 10 to the mobile 
node MN 8. 

[0036] An IP packet transmitted between networks, 

35 generally designated by reference numeral 1 4 and illus- 
trated in Figure 2(a), comprises an IP header 30, and 
an IP payload 22. The IP payload 22 is the information 
portion of the IP packet to be delivered to the mobile 
node 8. The parts of the IP packet which are relevant to 

40 the present discussion are illustrated in Figures 2(b) and 
2(c). The IP header 30, shown in Figure 2(b), includes 
a source address portion 16, a destination address por- 
tion 18, and a protocol ID portion 20. The IP header 30 
contains other fields which are not shown in Figure 2(b) 

45 since they are not relevant to the present explanation. 
[0037] Referring to Figure 2(c), the IP payload 32 in- 
cludes a source port number 34 and a destination port 
number 36. Again, the IP payload includes other fields 
which are not relevant for the purposes of the present 

so explanation. 

[0038] The source address 1 6 is the IP address of the 
host terminal (correspondent node) from which the IP 
packet is sent, and the destination address 18 is the IP 
home address of the host terminal (mobile node) to 

55 which the IP packet is to be sent. The source port 
number 34 is the port number used by an application at 
the correspondent node 1 0 associated with the IP pack- 
et 14. 
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[0039] The destination port number is the port number 
used by an application at the mobile node 8 to which the 
IP packet is being sent. In addition to other uses, the 
protocol ID 20 is one of the indicationsof the quality of 
service to be supported in signaling the IP packet from s 
the source applications to the destination applications. 
As will be appreciated by one familiar with the art, the 
destination and source addresses are used by routing 
switches between the correspondent node and the mo- 
bile node in the home network to route the IP packet to 10 
its destination. 

[0040] When the routers or routing switches support 
quality of service (QoS), in some QoS control provi- 
sions, such as RSVP and Intserv, the protocol ID 20 is 
used together with the source and destination address- '5 
es 16 and 18, plus the communication port numbers of 
end applications (i.e. the source port number 34 and the 
destination port number 36) for differentiating flows and 
imposing the necessary QoS control. 

[0041] The QoS control imposed on the data traffic 20 
flows at the intermediate routers is system dependent. 
For example, it can be the so-catled WFQ (Weighted 
Fair Queuing ) or CBQ (Classed Based Queuing). They 
are not standard and vendor specific but usually inde- 
pendent of the actual user's protocol ID. 25 
[0042] The lETF's IntSer/RSVP standard is defined to 
provide a QoS specification and signaling mechanism 
but not a QoS control mechanism. Intserve/RSVP is in- 
dependent of the actual QoS control mechanisms, such 
as WFQ, CBQ etc. 30 
[0043] The status based on which QoS control is per- 
formed is set up in the routing switches prior to data 
transmission by means of the specific quality of service 
signaling protocol, such as RSVP. 

[0044] A known way of routing an IP packet from the 35 
correspondent node to the mobile node MN 8 when it 
has moved to a position in the foreign network will now 
be described. When the mobile node MN 8 moves to a 
foreign network, it must register with the home agent HA 
1 2 of the home network so as to still be able to receive 40 
its messages when residing in the foreign network. This 
may be achieved by the mobile node sending a regis- 
tration message to the home agent HA 1 2 once it has 
taken up position in the foreign network. A mobile node 
can be considered to have taken up position in the for- 45 
eign network once it has been connected to the foreign 
network and been allocated a care-of address. 
[0045] Referring to Figure 3, the home agent HA 12 
includes a memory or look-up table generally designat- 
ed by reference numeral 24. In one column of the mem- so 
ory the home agent HA 1 2 stores the addresses of the 
mobile nodes normally resident in the home network 
that have registered with the home agent as being tem- 
porarily resident in a foreign network: In another column 
28 of the memory 24 the home agent stores the 'care- ss 
of address that the mobile node has moved to in the 
foreign network, as well as other associated states such 
as SPI (Security Parameter Index). 
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[0046] The technique by which the home agent 
records the current care-of address of the mobile node 
and its home address (i.e. the mobile node address in 
the home network), is usually implementation depend- 
ent. This invention does not exclude different approach- 
es for achieving the location -awareness of a mobile 
node at the home agent. 

[0047] The operation of the home agent in directing 
an IP packet from the correspondent node to the mobile 
node in the foreign network according to one current 
known technique will now be described. 
[0048] The correspondent node CN 10 constructs an 
IP packet having a format identical to that shown in Fig- 
ure 2(a). The thus constructed IP packet from the cor- 
respondent node is illustrated by the IP packet 50 in Fig- 
ure 4(a), and includes a source address 60 identifying 
the correspondent node address, a destination address 
62 identifying the home address of the mobile node in 
the' home network, and a protocol ID 66, nominally re- 
ferred to as protocol 'A'. The source port number and 
destination port number are not shown in Figures 4 and 
5 since they are not relevant to the explanation. 
[0049] In the example shown in Figure 1 , after moving 
to the foreign network 6 the mobile node 8 is allocated 
a unique 'care-of address of its own and registers di- 
rectly with the home agent 1 2 in the home network. This 
is known as COCOA (co-located care-of address) work- 
ing mode. An alternative working mode is known as FA- 
COA (foreign agent care-of address) working mode. 
The manner in which the mobile node may register with 
the home agent is well-known in mobile IP, and is not 
relevant to the present invention and therefore not dis- 
cussed herein. 

[0050] The IP packet constructed by the correspond- 
ent node 10 is identical whether the mobile node is po- 
sitioned in its home network 2 or in the foreign network 
6, as the correspondent node is not required to have 
knowledge of the movement of the mobile node. Mobile 
IP with route optimisation does, however, require that 
the correspondent node is aware of the current location 
of the mobile node. 

[0051] After a mobile node registers with the home 
agent using its current care-of address, the home agent 
will take a mobile node to be in a foreign network and 
starts intercepting the IP packets 50 destined to that mo- 
bile node home address and tunneling those IP packets 
to the mobile node's current care-of address. 
[0052] The home agent monitors all IP packets com- 
ing into the home network to see if the destination ad- 
dress in the home network (the portion 62 of the IP head- 
er fields 52) matches one of the mobile node home ad- 
dresses stored in column 26 of the home agent memory 
24. 

[0053] If a match is detected, the home agent creates 
a new IP packet, which is illustrated in Figure 4(b). The 
original IP packet from the correspondent node, includ- 
ing the destination address, source address, protocol 
ID, and other IP header fields and payload is used to 
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form part of the pay load of the new IP packet. That is, 
the original IP packet is not processed at all by the home 
agent but is merely incorporated, wholly unchanged, as 
the payload 32 of the new IP packet 30. 
[0054] The home agent then adds a destination ad- 
dress 36, source address 38 and protocol ID 40 to the 
new IP packet 30. 

[0055] The destination address 36 is the address in 
the foreign network where the IP packet is to be sent, 
that is the 'care-of address of the mobile node MN 8. 
The source address 38 is the address of the home agent 
from which the new IP packet 30 is being sent, i.e. the 
home agent. 

[0056] The home agent protocol ID is the protocol ID 
determined by the home agent itself. The home agent 
will always attach the same protocol ID to the new IP 
packet 30 regardless of the protocol ID 20 included in 
the original IP packet by the correspondent node, since 
the home agent does not look at the protocol ID 20 of 
the original IP packet 14. The protocol ID 40 is desig- 
nated nominally as protocol 'X'. For the conventional 
mobile IP's IP-in-IP's encapsulation, the protocol ID is 
always changed to "V by the home agent. 
[0057] Thus the 'real' source and destination address- 
es (60 and 62 of Figure 4(a)) have been moved into the 
payload of the new IP packet and the other necessary 
flow identification information such as source and des- 
tination port numbers in the original IP payload have al- 
so been wrapped up in the payload of the new IP packet. 
[0058] Thus, the original identity of a flow from the cor- 
respondent node to the mobile node is lost and quality 
of service fails as the IP packet is routed from the home 
agent to the foreign network. 

[0059] The IP packet 30 is then sent by the home 
agent, and is routed to arrive at the mobile node's 'care- 
of address in the foreign network. Once the IP packet 
30 arrives at the 'care-of address the mobile node strips 
the outer layers of the new IP packet 30 to reveal the 
original IP packet 50. 

[0060] Thus, it can be appreciated that in this known 
arrangement, the required flow identification information 
including the protocol ID in the original IP packet is 
shielded by the home agent and thus becomes unrec- 
ognizable by the routing switches (or IP routers) forQoS 
provision between the home agent and the mobile 
nodes 'care-of address. 

[0061] The routing of an IP packet from the corre- 
spondent node to the mobile nodes 'care-of address ac- 
cording to an alternative preferred implementation will 
now be described. In the scheme according to this al- 
ternative preferred implementation, the flow identifica- 
tion and differentiation information such as the original 
source address, the original source and destination port 
number, and the source protocol ID placed in the original 
IP packet by the correspondent node remains un- 
changed and thus is advantageously available to all the 
routing switches between the correspondent node and 
the mobile nodes 'care-of address. 
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[0062] The correspondent node constructs the IP 
packet 50 identically as before as shown in Figure 5(a). 
On arrival at the home network, the home agent 12 de- 
termines whether the mobile node to which the IP packet 
5 is addressed is registered as having moved to a foreign 
network, by checking the contents of its memory 24 as 
before. On detection of the destination address in its 
memory column 26, the home agent intercepts the IP 
packet. 

io [0063] In this implementation, the home agent HA 
adapts the IP packet 1 4 by removing the destination ad- 
dress 62 of the mobile node 8 in the home network 2, 
and replacing it with the destination address (i.e. the 
'care-of address) of the mobile node MN 8 in the foreign 

15 network 6. The new IP packet 42 thus comprises the 
payload 63 of the original IP packet 50, the source ad- 
dress 60 of the original IP packet 50, and the protocol 
ID 66 of the original IP packet 50. The destination ad- 
dress 62 of the original IP packet is replaced by the new 

20 destination address 41 (the mobile node's care-of ad- 
dress). 

[0064] Of course one familiar with the art will under- 
stand that it may be necessary to amend any error 
checking provided in the original IP packet 50 in view of 

2$ the change in the destination address. The thus con- 
structed new IP packet is sent to the 'care-of address 
in the foreign network. The IP packet is thus routed to 
the mobile node with the flow information including the 
source address of the correspondent node, and the orig- 

30 inal protocol I D as well as all other original flow identifi- 
cation information: it can be appreciated that as the pay- 
load remains unchanged, the source and destination 
port numbers are available in the same locations in the 
IP packet as before. 

35 [0065] The flow identification information is thus rec- 
ognized as the IP packet from the same correspondent 
node featuring the same QoS requirements to the rout- 
ers between the home agent and the 'care-of address 
as well as between the correspondent node and the 

40 home agent regardless of the movement of the mobile 
node. Advantageously, in this arrangement (co-located 
care-of address working mode), the new IP packet 42 
constructed by the home agent according to the present 
invention is the same length as the original IP packet 

45 provided by the correspondent node. 

[0066] In this preferred implementation of tunneling, 
the flow information is not hidden, and therefore the 
quality of service is apparently supported. However, for 
RSVP quality of service this is not the case. The reason 

50 for this is that for RSVP to correctly function , the transmit 
path followed by a so-called Reservation (Resv) mes- 
sage (routed hop-by-hop following the same hops as in- 
dicated by a so-called Path message) must be the same 
path but in the reverse direction of the Path message. 

55 That is the source address of the Path message must 
match the destination address of the Reservation 
(Resv) message, and the destination address of the 
Path message must match the source address of the 
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Reservation message. The below example of setting up 
an RSVP session in the network structure of Figure 1 
illustrates why the non-encapsulation mobile IP, as de- 
scribed hereinabove, is not sufficient to support quality 
of service. 5 
[0067] To support an RSVP session when the mobile 
node has moved into a foreign network as shown in Fig- 
ure 1, a two-section RSVP session must be set up: a 
first section of the RSVP session ("section 1 n ) between 
the correspondent node 1 0 and the home agent 1 2, and 10 
a second section of the RSVP session ("section 2") be- 
tween the home agent and the mobile node 8. 
[0068] The correspondent node 10, which in this ex- 
ample is assumed to be sending a message to the mo- 
bile node 8, sends a standard RSVP Path message in- is 
eluding IP packets 70 having the general format shown 
in Figure 6(a) on line 128. 

[0069] The IP packets of the messages used in an 
RSVP session do not have the format shown in Figures 
2(a) to 2(c). The IP packets of Figures 2(a) to 2(c) are 20 
IP packets of data messages. The IP packets 70 of the 
Path message of Figure 6(a) have a source address 78 
corresponding to the address of the correspondent 
node, and a destination address 80 corresponding to the 
address of the mobile node 8 in the home network (the 2$ 
mobile nodes home address). 

[0070] The I P packets of the Path message (and other 
RSVP messages) additionally include other flow identi- 
fication information in the payload of the IP packets. One 
skilled in the art will be familiar with the other flow iden- 30 
tification information. 

[0071] The IP packet of the Path message is routed 
from the correspondent node 10 to the home network 2 
via a plurality of routing switches, represented by routing 
switch 132a, on lines 128 and 124. 35 
[0072] If the routing switch 132a supports quality of 
service, then it extracts the flow identification informa- 
tion in the IP payload of the Path message IP packets, 
and stores this flow identification information. This flow 
identification information includes: the source address, *o 
the destination address, the source port number, the 
destination port number, and the protocol ID which will 
be included in all IP data packets transmitted from the 
source to the destination after the quality of service ses- 
sion has been set-up. The routing switch 132a routes 45 
the IP packets of the Path message to another routing 
switch, and then additionally stores with the flow identi- 
fication information extracted from the IP packet the ad- 
dress of the routing switch to which it sent the message 
(the next hop) and the address of the routing switch from so 
which it received the message (the previous hop). 
[0073] Although in Figure 1 it is illustrated that the IP 
packets reach the home network 2 via one routing 
switch 132a, in practice the IP packets may reach the 
home network via a plurality of routing switches, and 55 
each routing switch stores the flow identification infor- 
mation extracted from the IP packets of the Path mes- 
sage, together with the identity of the routing switch from 
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which the IP packet was sent and the routing switch to 
which the IP packet was sent. 

[0074] Thus the IP packets of the Path message travel 
from the correspondent node to the home network 
through the routing network. Each routing switch retains 
the address of the previous hop from which the IP packet 
was sent together with the next hop to which the IP pack- 
et was sent, and additionally the flow identification infor- 
mation for the I P packet. The routing switches also proc- 
ess the other traffic related information in the Path mes- 
sage, the nature of which is not relevant to a discussion 
of the present invention. 

[0075] After the quality of service session has been 
set-up, when another IP packet arrives at a particular 
routing switch having the same flow identification infor- 
mation that has been stored in the routing switch mem- 
ory, the routing switch forwards it to the exact same next 
hop, the address of which is stored in memory. 
[0076] Thus at successive hops, each routing switch 
(provided it supports RSVP quality of service) retrieves 
the flow identification information from the fixed loca- 
tions of the IP packets of the Path message and stores 
them in memory, together with the addresses of the next 
and previous hops. Thus the flow identification informa- 
tion in the IP packets helps to uniquely identify a mes- 
sage flow, so that all IP packets associated with that 
message flow can be routed from the source to the des- 
tination through the exact same network path. 
[0077] The home agent then intercepts the I P packets 
of the Path message intended for the mobile node. 
When the home agent intercepts the IP packets of the 
Path message destined for the mobile node 8, it redi- 
rects them to the foreign network. In this example non- 
encapsulation mobile IP is utilised, and new IP packets 
are created for transmission to the foreign network as a 
new, or modified, Path message. The IP packets 74 of 
the modified Path message sent by the home agent are 
shown in Figure 6(b). 

[0078] The home agent replaces the destination ad- 
dress of the IP packets of the Path message, such that 
the destination address 106 of the IP packets 74 of the 
modified Path message is the mobile node's care-of ad- 
dress in the foreign network. As discussed hereinabove, 
in non-encapsulation mobile IP all other elements of the 
IP packets 70 remain unchanged. 
[0079] This modified Path message is routed to the 
mobile node's care-of address via routing switches rep- 
resented by the single routing switch 1 32b, on lines 1 26 
and 130. 

[0080] As described hereinabove in relation to the first 
section of the Path message, in the second section of 
the Path message the IP packets of the modified Path 
message are similarly transmitted based on the flow 
identification information therein. The next and previous 
hops are similarly stored by the routing switches. 
[0081] The mobile node receives the modified Path 
message and initiates the Reservation (Resv) message 
for the second section by creating a Reservation mes- 
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sage for transmission having IP packets 76 of the gen- 
eral format as illustrated in Figure 6(c). 
[0082] It will be understood by one skilled in the art 
that the IP packets of a Reservation message (Resv) 
are transmitted hop-by-hop back along the identical net- 
work path as the IP packets of the Path message. Thus 
the source and destination addresses of the IP packets 
of the Reservation messages are actually the last and 
previous hops. The value of the source and destination 
addresses are thus determined dynamically as the Res- 
ervation messages transit through the path. Thus the 
structure of the IP packets 76 of the Reservation mes- 
sage shown in Figure 6(c) is actually representative of 
the transport layer of the Reservation messages. Thus 
the structure shown in Figure 6(c) illustrates the general 
concept of a Reservation message, that is the originat- 
ing source address and the ultimate destination ad- 
dress. This analysis of the Reservation message is 
somewhat artificial, but serves to best illustrate the prin- 
ciple of RSVP. 

[0083] The mobile node 8 identifies the source ad- 
dress 1 1 4 as the mobile node's home address. Standard 
mobile IP provides that the applications on a mobile 
node itself should not be required to be aware of the 
change of the mobile nodes network attachment points. 
Therefore regardless of the location of the mobile node 
(whether in its home network or a foreign network) the 
mobile node always generates IP packets which identify 
the source address as being the mobile node's homes 
address. The mobile node includes a destination ad- 
dress in the Reservation message of the correspondent 
node address. This is because, in accordance with 
standard mobile IP, the mobile node is aware that the 
message came from the correspondent node, and is not 
aware of the redirection via the home agent. 
[0084] For IP packets sent from the mobile node to 
the correspondent node in standard mobile IP, they are 
routed as normal IP packets as if the mobile node were 
'at home* in the home network. 

[0085] Comparing the IP packets of the Path and Res- 
ervation messages shown Figures 6(b) and 6(c), the 
conditions for a successful RSVP session do not exist. 
The source address of the reservation message 76 is 
different to that of the destination address of the path 
message 74. 

[0086] This results in the failure of the routing of the 
Reservation (Resv) message hop-by-hop following the 
same network path as that set by the IP packets of the 
Path message. The Reservation message for the first 
section (between the home agent and the correspond- 
ent node) is never initiated because the second section 
fails. 

[0087] Referring to Figure 7, there is shown the net- 
work arrangement of Figure 1 adapted to enable non- 
encapsulation mobile IP to support RSVP. In the ar- 
rangement shown a proxy server is introduced into the 
correspondent network and the foreign network. How- 
ever, it should be understood from the following descrip- 



tion that the functionality of the proxy server may in prac- 
tice be incorporated into the host terminals to which the 
proxy servers are connected. A further explanation is 
given hereinbelow following the explanation of the ar- 

5 rangement of Figure 7. 

[0088] Referring to Figure 7, the networks of Figure 1 
are adapted such that the correspondent network 4 ad- 
ditionally includes a correspondent network proxy serv- 
er 142 and the foreign network 6 additionally includes a 

io foreign network proxy server 144. The correspondent 
node 10 is connected to the correspondent node proxy 
server 142 via a network link 138. The correspondent 
network proxy server connects to the routing switches 
via a network link 128. The foreign network proxy server 

is 1 44 connects to the mobile node 8 in the foreign network 
6 via a network link 1 46. The foreign network proxy serv- 
er connects to the routing switch 1 32b via the network 
link 136. 

[0089] An example of the operation of the adapted 

20 network of Figure 8 for sending a message from the cor- 
respondent node 10 to the mobile node 8 in the foreign 
network using non-encapsulation mobile IP in which 
RSVP is supported will now be described. 
[0090] Each host terminal which requires quality of 

25 service provision in a network needs to be aware of the 
existence of a proxy server in the network. That is, there 
must be a process by which the host terminals can dis- 
cover proxy servers. There are effectively two ways this 
can happen. In a first way, host terminals in the network 

30 broadcast a server soliciting message (SSM). A proxy 
server in the network responds by sending back to the 
host terminal a server response message (SRM). In a 
second way, the proxy server in a network broadcasts 
a client request message (CRQM) to the local network. 

35 Responsive thereto, host terminals (which can be con- 
sidered to be proxy server clients) send back a client 
registration message (CRGM). In this way the presence 
of the proxy servers in the networks is registered by host 
terminals in the networks in much the same way as the 

40 presence of agents (home agents, foreign agents) is 
currently registered in standard mobile IP. 
[0091 ] The implementation of the technique for nodes 
to register with proxy servers will be within the scope of 
one skilled in the art. 

45 [0092] As discussed hereinabove, to successfully es- 
tablish a quality of service session between the corre- 
spondent node and the mobile node when the corre- 
spondent node is sending a message to the mobile 
node, it is necessary to establish an RSVP session with 

so two sections. Generally speaking, a first section of the 
quality of service session must be established between 
the correspondent network and the mobile nodes home 
network, and a second section of the quality of service 
session must be established between the home network 

55 and the foreign network. 

[0093] The technique for establishing the first quality 
of service session, and particularly an RSVP session in 
mobile IP, for the network arrangement of Figure 7, will 
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now be described with the aid of the flow diagram of Fig- 
ure 8. According to the present invention, in a step 150 
the correspondent node 1 4a initiating a quality of service 
session sends a quality of service request on network 
link 1 38 to the correspondent network proxy server 1 42. 
[0094] The quality of service request may be implicit 
or explicit. An explicit quality of service request from the 
correspondent node specifies an exact quality of service 
requirement. Thus an explicit quality of service request 
can be provided only by a correspondent node which 
has the functionality to support the explicit statement of 
a particular quality of service. An implicit quality of serv- 
ice request from the correspondent specifies only the 
nature of the transmission to be made. For example, an 
implicit quality of service request may indicate that the 
data to be sent is video data. The proxy server then de- 
termines the appropriate quality of service in depend- 
ence on the indication of the type of data. 
[009S] The correspondent network proxy server 142, 
in a step 1 52, then sends a standard RSVP Path mes- 
sage. This Path message is communicated to the home 
network proxy server via the routing switch 1 32a on lines 
1 28 and 1 24. 

[0096] The IP packets of the Path message sent by 
the correspondent node proxy server corresponds iden- 
tically to IP packets 70 of Figure 6(a), and are routed by 
the routing network comprising the routing switches 1 32 
to the home agent 12. The routing takes place in exactly 
the same manner as described before. 
[0097] In a step 1 54 the home agent intercepts the IP 
packets of the Path message, and adapts the IP packets 
as described above to generate the IP packets for the 
modified the Path message. 

[0098] The IP packets of the modified Path message 
correspond identically to the IP packets 74 of Figure 6 
(b). In a step 156 the IP packets comprising the second 
section of the Path message 74 are transmitted by the 
home agent and routed via the routing network repre- 
sented by the routing switch 1 32b to the foreign network 
144. 

[0099] The foreign network proxy server receives the 
second section of the Path message, and in a step 158, 
the foreign network proxy server 144 sends a quality of 
service indication signal to the mobile node 8 on line 
146, indicating the quality of service requested by the 
correspondent node 10. If the quality of service level is 
acceptable to the mobile terminal, the mobile terminal 
sends a quality of service response by way of acknowl- 
edgement to the foreign network proxy server 144 in a 
step 160 on network link 146. 

[0100] In a step 162 the foreign network proxy server 
then sends a modified Reservation message (i.e. mod- 
ified relative to the Reservation message sent with 
standard mobile IP), confirming the quality of service 
session. The modified Reservation message follows the 
identical route to the Path message (in reverse) via lines 
136 and 126. 

[0101] The format of the modified reservation mes- 



sage 77, for the second RSVP session, sent back by the 
foreign network proxy server is illustrated in Figure 6(d). 
As.can be seen, because of the use of the foreign net- 
work proxy server 144 the source address 115 is the 

5 mobile node care-of address, and the destination ad- 
dress is the correspondent node's address. Thus the 
correct correlation exists between the source and des- 
tination addresses of the Path and Reservation messag- 
es in the second RSVP session, such that the RSVP 

io session is supported. 

[0102] Again, the message shown in Figure 6(d) is 
representative of the end-to-end message between the 
foreign network and the home network. The format 
shown in Figure 6(d) is not representative of the IP pack- 
's ets of the Reservation message, which as discussed 
above have source and destination addresses corre- 
sponding to the previous and next hops. 
[0103] In a step 164 the home agent receives the 
modified Reservation message. The home agent 

20 adapts the Reservation message to the form shown in 
Figure 6(e), which forms a further modified Reservation 
message. In order to perform this adaptation, the home 
agent is provided with the functionality of a proxy server 
therein. Alternatively a home network proxy server, 

25 equivalent to the correspondent network and foreign 
network proxy servers, may be provided in the home 
network and be associated with the home agent. 
[0104] The RSVP session is completed by the home 
agent sending the further modified Reservation mes- 

30 sage back to the correspondent network via the routing 
switch 132a and the network links 124 and 128. As 
shown in Figure 6(e) the Reservation message has as 
the source address 88 the home address of the mobile 
node, and as the destination address the address of the 

35 correspondent node. Thus the section of the RSVP ses- 
sion between the correspondent network and the home 
network is equivalent to a standard static RSVP session. 
The flow information required by the routing switches in 
the routing networks to support RSVP is fully available. 

40 The source and destination addresses are 'swapped' in 
the further modified Reservation message relative to the 
Path message. 

[0105] In a step 166 the home agent then sends the 
Reservation message for the first section. The further 

45 modified Reservation message is then sent to the cor- 
respondent network 4 where it is received by the corre- 
spondent network proxy server 142. 
[0106] The correspondent network proxy server then 
sends, in a step 168, a quality of service confirmation 

50 message on the network link 138 by way of acknowl- 
edgement to the correspondent node 10, indicating that 
the quality of service session has been set up. 
[01 07] The correspondent node 1 0 then begins send- 
ing data message packets to the mobile terminal. How- 

55 ever the data message packets do not go via the corre- 
spondent network proxy server or the foreign network 
proxy server. The proxy servers are used only during 
the set-up of the RSVP session. 
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[0108] Once the RSVP session is set-up as de- 
scribed, and messages are sent from the correspondent 
node to the mobile node, it is essential that the flow iden- 
tification information carried by the IP packets of the da- 
ta message match that used in the set-up of the RSVP s 
session. Thus the IP data packets, having the general 
format shown in Pigure 2, must include the same source 
port number, destination port number, and protocol ID 
contained in the payload of the RSVP message, as well 
as the source and destination addresses. In this way the io 
data IP packets are uniquely identified as being associ- 
ated with the flow configured by the RSVP session. 
[01 09] Thus the provision of the foreign network proxy 
server ensures that the RSVP quality of service is sup- 
ported in mobile IP. The proxy servers shown in Figure 15 
7 can thus be considered to be "RSVP proxy servers". 
The proxy servers dynamically adapt the destination of 
the RSVP messages to follow the movement of the mo- 
bile node and in the meantime, guarantee that the flow 
identification information and quality of service informa- 20 
tion match the data flows directed according to non-en- 
capsulation mobile IP (NEMIP). 

[0110] It will be appreciated from the foregoing de- 
scription that it is essential that the proxy server (or the 
equivalent functionality of the proxy server) is provided 2s 
in the foreign network, that is a network which accom- 
modates host terminals normally resident in other net- 
works, if quality of service is to be supported in mobile IP. 
[0111] The provision of the RSVP proxy server (or its 
functional equivalent) in the foreign network guarantees so 
that the established RSVP session (in particular, the 
second section of the RSVP session) follows the move- 
ment of the mobile node whilst at the same time record- 
ing the correct flow information matching that of the data 
flows which follow that same path of the RSVP session, 35 
regardless of the change of the mobile node's point of 
network attachment. 

[0112] No host terminal, when transmitting, will know 
whether the host terminal it is transmitting to is a mobile 
node, or whether it is in a foreign network having an 40 
RSVP proxy server. To ensure support of RSVP with 
mobile IP, each network which is capable of acting as a 
foreign network to host mobile nodes should be provid- 
ed with a proxy server (or its equivalent functionality) 
with the functions as described herein. The above de- 45 
scription of the functional control as performed by the 
proxy server in a foreign network is essential to support- 
ing quality of service in a mobile environment. 
[0113] Referring to Figure 7, the essential require- 
ment to support a quality of service session for a corre- so 
spondent node in the correspondent network desiring to 
send data messages to the mobile node, is that the for- 
eign network in which the mobile node is located must 
have a proxy server or its functional equivalent. The cor- 
respondent node can then directly set up the RSVP ses- 55 
sion itself without the need of the correspondent node 
proxy server. 

[0114] The provision of the correspondent node proxy 



server, however, has the advantage that it enables ter- 
minals in the correspondent node not having RSVP 
functionality to initiate RSVP sessions. The proxy server 
provides a technique for configuring a quality of service 
session which is both platform and application inde- 
pendent. By providing a dedicated means for establish- 
ing quality of service sessions, then current and future 
quality of service incapable host terminals can have a 
quality of service session set-up and thus their quality 
of .service control enabled across the transmit Path to 
their communication peers. The requirements for com- 
plicated and intensive computing as induced in many 
quality of service control signaling and control mecha- 
nisms, and strain on battery power for wireless/mobile 
terminals, is avoided. 

[0115] In an alternative application, as mentioned 
consistently hereinabove, the functionality of the proxy 
server performed in the foreign network is performed in 
the mobile node itself. In such an application the mobile 
node will already be RSVP capable, and will have an 
RSVP daemon to support standard RSVP sessions. In 
such an application responsive to receipt of the modified 
Path message from the home network the mobile node 
will generate the standard RSVP message format 
shown in Figure 6(c). The proxy server functionality em- 
bedded in the RSVP daemon of the mobile node will 
then modify this Reservation message to generate the 
modified Reservation message of Figure 6(d). The mod- 
ified Reservation message is then transmitted directly 
from the mobile node. 

[0116] It should be noted that the examples described 
herein throughout this text utilise standard RSVP. No 
change to the standard RSVP/lntServ is envisaged or 
proposed. 

[0117] The invention has been described herein with 
reference to a particular example of an RSVP quality of 
service session which utilises Path and Reservation 
messages. However, the invention is more generally ap- 
plicable to any quality of service session which utilises 
request and reply messages between two terminals for 
configuring a quality of service session, and where there 
is a requirement to overcome the problem identified 
herein. 



Claims 

1. A method of establishing a quality of service ses- 
sion between a correspondent node and a mobile 
node, the mobile node having a home address in a 
home network and being temporarily connected at 
a care-of address in a foreign network, the method 
including the steps of: generating, in the foreign net- 
work, a modified reply message having a source ad- 
dress of the mobile node's care-of address and a 
destination address of the correspondent node; and 
transmitting the modified reply message. 
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2. The method of claim 1 , further comprising the steps 
of: receiving, in the home network, a request mes- 
sage having a source address of the correspondent 
node and a destination address of the mobile node's 
home address; creating a modified request mes- 5 
sage by replacing the destination address of the re- 
quest message with the mobile node's care-of ad- 
dress; and transmitting the modified request mes- 
sage to the foreign network, whereby the reply mes- 
sage is generated responsive to the modified re- 10 
quest message. 

3. The method of claim 1 or claim 2 further comprising 
the steps of: receiving in the home network, the 
modified reply message; creating a further modified is 
reply message by replacing the source address with 

the mobile node's home address; and transmitting 
the further modified reply message. 

4. The method of any one of claims 1 to 3 in which the 20 
step of generating the modified reply message is 
carried out in the mobile node. 

5. The method of claim 4 wherein the step of generat- 
ing the modified reply message comprises: gener- 25 
ating a reply message having a source address of 

the mobile node's home address and a destination 
address of the correspondent node; and replacing 
the source address with the mobile node's care-of 
address, thereby generating the modified reply 30 
message. 
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responsive to receipt of the further modified reply 
message. 

10. A mobile IP environment capable of supporting a 
quality of service session, including a correspond- 
ent node and a mobile node, the mobile node hav- 
ing a home address in a. home network and being 
temporarily connected at a care-of address in a for- 
eign network, the foreign network having means as- 
sociated with the mobile node for generating a mod- 
ified reply message having a source address of the 
mobile node's care-of address and a destination ad- 
dress of the correspondent node. 

11. The mobile IP environment of claim 10 in which the 
means is provided in the mobile node. 

12. The mobile IP environment of claim 10 in which the 
means is provided separate to the mobile node. 

1 3. The method or environment of any preceding claim 
in which the quality of service session is an RSVP 
session, the request message is a Path message, 
and the reply message is a Reservation message. 



6. The method of any one of claims 1 to 3 in which the 
step of generating the modified reply message is 
carried out by proxy means in the foreign network 3$ 
associated with the mobile node. 



7. The method of claim 6 when dependent on claim 2, 
further comprising the steps of: responsive to re- 
ceipt of the modified request message at the proxy 40 
means, sending a quality of service indication signal 
to the mobile node, whereby the modified reply 
message is generated responsive to receipt of a 
quality of service acknowledgement from the mo- 
bile node. 45 



8. The method of any one of claims 3 to 7, wherein the 
correspondent node generates the request mes- 
sage and receives the further modified reply mes- 
sage, so 



9. The method of any one of claims 3 to 7, wherein the 
correspondent node is associated with a corre- 
spondent proxy means, whereby the correspondent 
proxy means generates the request message re- 55 
sponsive to a quality of service request from the cor- 
respondent node, and the correspondent proxy 
means generates a quality of service confirmation 
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